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Copyright Notice 
Copyright (C) The IETF Trust (2007). 
IESG Note 


This document describes an existing deployed technology that was 
developed outside the IETF. It utilizes the RADIUS Access-Reject in 
order to provision service, which is incompatible with the RADIUS 
protocol, and practices the sharing of secret keys in public-key 
cryptosystems, which is not a practice the IETF recommends. The IESG 
recommends against using this protocol as a basis for solving similar 
problems in the future. 


Abstract 


The Verizon Wireless Dynamic Mobile IP Key Update procedure is a 
mechanism for distributing and updating Mobile IP (MIP) cryptographic 
keys in cdma2000(R) networks (including High Rate Packet Data, which 
is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update 
(DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS 
Authentication, Authorization and Accounting (AAA) Server via a 
cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a 
Mobile IP Foreign Agent (FA). 


cdma2000(R) is a registered trademark of the Telecommunications 
Industry Association (TIA). 
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Introduction 


The Verizon Wireless Dynamic Mobile IP Key Update procedure is a 
mechanism for distributing and updating Mobile IP (MIP) cryptographic 
keys in cdma2000(R) 1xRTT (1X) [2] and High Rate Packet Data (HRPD) / 
1xEV-DO networks [3]. The Dynamic Mobile IP Key Update (DMU) 
procedure occurs between the Mobile IP Mobile Node (MN) and the home 
RADIUS [4] (or Diameter [5]) Authentication, Authorization and 
Accounting (AAA) Server via a cdma2000 (R) Packet Data Serving Node 
(PDSN) that is acting as a Mobile IP Foreign Agent (FA). (In this 
document, we use the acronym AAAH to indicate the home AAA server as 
opposed to an AAA server that may be located in a visited system.) 
This procedure is intended to support wireless systems conforming to 
Telecommunications Industry Association (TIA) TR-45 Standard IS-835 
[6]. DMU, however, could be performed in any MIP network to enable 
bootstrapping of a shared secret between the Mobile Node (MN) and 
RADIUS AAA Server. 


The DMU procedure utilizes RSA public key cryptography to securely 
distribute unique MIP keys to potentially millions of cdma2000 (R) 1X 
and HRPD/1xEV-DO Mobile Nodes (MN) using the same RSA public key. 


By leveraging the existing cdma2000(R) 1X authentication process, the 
Dynamic Mobile IP Key Update process employs a mutual authentication 
mechanism in which device-to-network authentication is facilitated 
using cdma2000 (R) 1X challenge-response authentication, and network- 
to-device authentication is facilitated using RSA encryption. 


By utilizing RSA encryption, the MN (or MN manufacturer) is able to 
pre-generate MIP keys (and the Challenge Handshake Authentication 
Protocol (CHAP) key) and pre-encrypt the MIP keys prior to initiation 
of the DMU procedure. By employing this pre-computation capability, 
the DMU process requires less computation (by an order of magnitude) 
during the key exchange than Diffie-Hellman Key Exchange. 


Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 


Basic Dynamic MIP Key Update Mechanism 


The DMU procedure is basically an authentication and key distribution 
protocol that is more easily understood by separately describing the 
mechanism’s two functional goals: 1) encrypted key distribution and 
2) mutual authentication. 
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RSA Encrypted Key Distribution 


By utilizing RSA public key cryptography, MNs can be pre-loaded with 
a common RSA public (encryption) key (by the MN manufacturer), while 
the associated RSA Private (decryption) key is securely distributed 
from the MN manufacturer to a trusted service provider. 
Alternatively, a service provider can generate its own RSA 
public/private key pair and only distribute the RSA public key to MN 
manufacturers for pre-loading of MNs. 


During the manufacturing process, the MN manufacturer pre-loads each 
MN with the RSA public key. When the MN is powered-up (or client 
application initiated), the MN can pre-generate and encrypt MIP keys 
for distribution to the Home RADIUS AAA Server during the DMU 
process. Alternatively, the MN manufacturer can pre-generate MIP 
keys, encrypt the MIP key payload, and pre-load the MN with multiple 
encrypted MIP key payloads to enable the DMU procedure. 


During the initial registration process (or when the AAA requires MIP 
key update), the MN: 1) generates the appropriate MIP keys, CHAP key, 
and authentication information, 2) uses the embedded RSA public key 
to encrypt the payload information, 3) and appends the payload to the 
MIP Registration Request. The Registration Request is sent to the 
Mobile IP Foreign Agent (FA) via the cellular Base Station (BS) and 
Packet Data Serving Node (PDSN). When the RADIUS AAA Server receives 
the encrypted payload (defined later as MIP_Key_Data), the AAA Server 
uses the RSA Private key to decrypt the payload and recover the MIP 
keys. 
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MN BS/PDSN/FA AAA 


| RSA Public Key | | RSA Private Key | 
| Pre-loaded by | | Pre-loaded by | 
| Manufacturer | Service Provider 


(MIP keys), RSA 
Public Key 


| 
| 
| 
| 
Registration Request, 
| 
| 
| Access Request, (MIP keys), 
| RSA Public Key | 
| 


| Decrypt MIP | 
Keys using RSA | 
Private Key | 


Figure 1. RSA Encrypted Key Distribution 
2.2. Mutual Authentication (1X) 


Mutual authentication can be achieved by delegation of the MN/device 
authentication by the RADIUS AAA Server to the cdma2000 (R) 1X Home 
Location Register (HLR) and its associated Authentication Center (AC) 
[7], while the MN utilizes RSA encryption to authenticate the RADIUS 
AAA Server. 


MN/device authentication via an HLR/AC is based on the assumption 
that the MN’s Mobile Station (MS) has an existing Authentication Key 
(A-key) and Shared Secret Data (SSD) with the cdma2000(R) 1X network. 
When MS call origination occurs, the AC authenticates the MS. If 
authentication is successful, the BS passes the Mobile Station 
Identifier (MSID) (e.g., Mobile Identification Number (MIN)) to the 
PDSN. The "Authenticated MSID" is then included in the RADIUS Access 
Request (ARQ) message [4] sent from the PDSN to the RADIUS AAA 
server. Because the RADIUS AAA server stores the MSID associated 
with an MN subscription, the RADIUS AAA server is able to authorize 
MN access if the "Authenticated MSID" matches the RADIUS AAA MSID, 
i.e., the RADIUS AAA server is delegating its authentication function 
to the cdma2000(R) 1X HLR/AC. 
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RADIUS AAA Server authentication (by the MN) is enabled by including 
a random number (AAA Authenticator) in the encrypted payload sent 
from the MN to the RADIUS AAA Server. Only the possessor of the 
proper RSA Private key will have the ability to decrypt the payload 
and recover the unique AAA Authenticator. If the MN receives the 
correct AAA Authenticator (returned by the RADIUS AAA Server), the MN 
is assured that it is not interacting with a false Base Station (BS). 
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MN BS/PDSN/FA HLR/AC AAA 


| RSA Private Key | 
| Pre-loaded by | 
| Service Provider | 


| Pre-loaded by | 


| RSA Public Key | | 
| 
| Manufacturer | 


| 
En | 
| Auth_Response | 
Lo > | 
| | Auth_Response | 
po [e > | 
| o nnn | 
IS-2000 
| | | Authentication | | 
| E === | 
| | Auth_Success | | 
| | <-> | | 
A | | 
BS forwards 
| | Authenticated | | 
| | MSID to PDSN | | 
J ===- | 
| | | | 
| Registration Request 
(MIP keys, AAA Authenticator), 
RSA Public Key 
| >| | | 
| | Access Request, MSID, | 
| | (MIP keys, AAA Authenticator), 
| | RSA Public Key | 
O dr penes >| 
| A A A E 
| | | | Check MSID, | 
| | | | Decrypt AAA_- 
| | | | Authenticator 
| > 
Access Reject, AAA Authenticator 
| <------------------------------- 
Registration Reply, AAA Authenticator 
ao | | | 
| Check AAA_- | | | | 
| Authenticator | | 


Figure 2. Mutual Authentication 
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2.3. Encrypted Password Authentication 


Because cdma2000(R) A-key/SSD authentication is not available in 
1xEV-DO, or a particular cdma2000(R) 1X network may not support A-key 
authentication, the DMU procedure also includes a random number 
(MN_Authenticator) generated by the MN (and/or pre-loaded by the 
manufacturer), which enables the RADIUS AAA Server to optionally 
authenticate the MN (in 1XEV DO network only). 


The MN_Authenticator is transmitted from the MN to the Home AAA 
Server within the RSA-encrypted MIP_Key_Data payload to prevent 
interception and possible re-use by an attacker. Ideally, the 
MN_Authenticator is utilized as a One-Time Password; however, RSA 
encryption allows the MN_Authenticator to possibly be re-used based 
on each service provider’s key distribution policy. 


When the encrypted MIP keys are decrypted at the Home RADIUS AAA 
Server, the MN_Authenticator is also decrypted and compared with a 
copy of the MN_Authenticator stored within the Home RADIUS AAA 
Server. The Home RADIUS AAA Server receives a copy of the 
MN_Authenticator out-of-band (not using the cdma2000(R) network) 
utilizing one of numerous possible methods outside the scope of the 
standard. For example, the MN_Authenticator MAY be: 1) read out by a 
Point-of-Sale provisioner from the MN, input into the subscriber 
profile, and delivered, along with the Network Access Identifier 
(NAI), via the billing/provision system to the Home RADIUS AAA 
server, 2) verbally communicated to a customer care representative 
via a call, or 3) input by the user interfacing with an interactive 
voice recognition server. The out-of-band MN_Authenticator delivery 
is not specified in this document to maximize the service provider’s 
implementation flexibility. 


It is possible for an unscrupulous provisioner or distribution 
employee to extract the MN_Authenticator prior to the DMU procedure; 
however, the risk associated with such a disclosure is minimal. 
Because the HRPD/1xEV-DO MN does not transmit a device identifier 
during the initial registration process, an attacker, even with a 
stolen MN_Authenticator, cannot correlate the password with a 
particular MN device or NAI, which is typically provisioned just 
prior to DMU procedure initiation. 


The MN_Authenticator is typically generated by a random/pseudorandom 
number generator within the MN. MN_Authenticator generation is 
initiated by the MN user; however, it may be initially pre-loaded by 
the manufacturer. When the MN_Authenticator is reset (i.e., a new 
MN_Authenticator is generated), all MIP_Data_Key payloads using the 
previous MN_Authenticator are discarded and the MN immediately re- 


Carroll & Quick Informational [Page 8] 


RFC 4784 Dynamic MIP Key Update June 2007 


encrypts a MIP_Key_Data payload containing the new MN_Authenticator. 
The MN_Authenticator MUST NOT change unless it is explicitly reset by 
the MN user. Thus, the MN will generate new MIP_Key_Data payloads 
using the same MN_Authenticator until the MN_Authenticator is 
updated. 


| User-initiated | 
MN_Authenticator [x] 
Generation 


| Manufacturer | | Delete MN_Authenticatorlyl, | 
MN _Authenticator[y] = = 3 |----- > Store MN_Authenticator[x] 
Generation** in MN 


Delete MIP_Key_ Data 
Payloads based on 
| MN_Authenticator [y] | 


| KEYS_VALID state and | | Generate MIP_Key_Data | 
| committed, delete |----- >| Payloads based on 
| MIP_Key_Data Payload | | MN_Authenticator[x] | 


| DMU MIP_Key_Data | | Store MIP_Key_Data | 
| Delivery |<----- | Payload | 


Figure 3. MN_Authenticator and MIP_Key_Data Payload State Machine 


**Note: Manufacturer pre-load of MN_Authenticator is not essential 
since the MN_Authenticator is typically generated by the MN. 
However, manufacturer pre-load may reduce the provisioner burden of 
accessing a device such as a modem to recover the MN_Authenticator 
for entry into the service provider provisioning system. 
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3. Dynamic MIP Key Update Advantages over OTASP 


The DMU procedure has numerous advantages over the current Over-the- 
Air Service Provisioning (OTASP) [8] procedure, including: 


* In DMU, MIP key distribution occurs directly between the MN and 
AAA Server at the IP Layer. This eliminates the need for an 
interface between the Over-the-Air Functionality (OTAF) and 
RADIUS AAA server. 


* DMU Supports MIP key distribution for cdma2000(R) 1X and 
HRPD/1xEV-DO MN. OTASP only supports cdma2000(R) 1X MIP key 
distribution. 


* DMU facilitates MIP key distribution to an MN in a Relay-mode 
MS. OTASP only delivers the MIP keys to the MS. For example, 
OTASP cannot deliver MIP keys to a Laptop MN interfacing with 
an MS modem. 


* Pre-encryption of MIP_Key_ Data allows the DMU procedure to be 
an order of magnitude faster than Diffie-Hellman Key Exchange. 


* In DMU, an MN manufacturer can pre-generate MIP keys, pre- 
encrypt the MIP key payload, and pre-load the payload in the 
MN. Thus, an MN with limited processing power is never 
required to use RSA encryption. An OTASP device is always 
forced to perform computationally expensive exponentiations 
during the key update process. 


* In DMU, the MN is protected against Denial-of-Service (DOS) 
attacks in which a false BS changes the MIP key for MNs in its 
vicinity. OTASP Diffie-Hellman Key Exchange is vulnerable to a 
false BS DOS attack. 


* DMU utilizes mutual authentication. OTASP Diffie-Hellman Key 
Exchange does not utilize mutual authentication. 


4. Detailed DMU Procedure Description and Requirements 


The Verizon Wireless Dynamic Mobile IP Update procedure is a secure, 
yet extremely efficient mechanism for distributing essential MIP 
cryptographic keys (e.g., MN-AAAH key and MN-HA key) and the Simple 
IP CHAP key. The DMU protocol enables pre-computation of the 
encrypted key material payload, known as MIP_Key_Data. The DMU 
procedure purposely avoids the use of Public Key Infrastructure (PKI) 
Certificates, greatly enhancing the procedure’s efficiency. 
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4.1. RSA Public Key Cryptography 


RSA public key encryption and decryption MUST be performed in 
accordance with RFC 3447 [9] PKCS #1: RSA Encryption Version 1.5. DMU 
MUST support RSA with a 1024-bit modulus by default. DMU MAY also 
support 768-bit or 2048-bit RSA, depending on the MN user's 
efficiency or security requirements. RSA computation speed-ups using 
a public RSA exponent that is small or has a small number of nonzero 
bits (e.g., 65537) are acceptable. 


4.2. Other Public Key Algorithms 
DMU does not preclude the use of other public key technologies. The 
protocol includes a Public Key Type field that defines the type of 


encryption used. 


4.3. Why No Public Key Infrastructure (PKI)? 


DMU is designed to maximize the efficiency of Mobile IP (MIP) key 
distribution for cdma2000(R) MNs. The use of a public key 
Certificate would improve the flexibility of the MIP key update 
process by allowing a Certificate Authority (CA) to vouch for the RSA 
public key delivered to the MN. Unfortunately, the use of a public 
key certificate would significantly reduce the efficiency (speed and 
overhead) of the MIP key update process. For instance, each MN must 
be pre-loaded with the CA’s public key. During the MIP key 
distribution process, the network must first deliver its RSA public 
key (in a certificate) to the MN. The MN must then use RSA to 
decrypt the Certificate’s digital signature to verify that the 
presented RSA public key is legitimate. Such a process significantly 
increases the number of exchanges, increases air interface overhead, 
increases the amount of MN computation, and slows the MIP key update 
process. 


Aside from the operational efficiency issues, there are numerous 
policy and procedural issues that have previously hampered the 
deployment of PKI in commercial networks. 


On a more theoretical basis, PKI is likely unnecessary for this key 
distribution model. PKI is ideal for a Many-to-Many communications 
model, such as within the Internet, where many different users 
interface with many different Websites. However, in the cellular/PCS 
Packet Data environment, a Many-to-One (or few) distribution model 
exists, in which many users interface with one wireless Carrier to 
establish their Mobile IP security associations (i.e., cryptographic 
keys). 
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4.4. Cryptographic Key Generation 


The DMU procedure relies on each MN to randomly/pseudo-randomly 
generate the MN_AAAH key, MN_HA key, and Simple IP CHAP key. Each MN 
MUST have the capability to generate random/pseudo-random numbers in 
accordance with the guidelines specified in RFC 4086 "Randomness 
Requirements for Security". 


Although it may be more secure for the network to generate 
cryptographic keys at the RADIUS AAA server, client cryptographic key 
generation is acceptable due to the significant efficiency 
improvement in the update process via pre-generation and pre- 
encryption of the MIP keys. 


4.5. MIP_Key_Data Payload 


MIP cryptographic keys (MN_AAAH key and MN_HA key) and the Simple IP 
CHAP key are encapsulated and encrypted into a MIP_Key_Data Payload 
(along with the AAA Authenticator and MN_Authenticator). The 
MIP_Key_ Data Payload is appended to the MN’s MIP Registration Request 
(RRQ) as a MIP Vendor/Organization-Specific Extension (VSE) (see RFC 
3115 [10] Mobile IP Vendor/Organization-Specific Extensions). When 
the PDSN converts the MIP RRQ to a RADIUS Access Request (ARQ) 
message, the MIP_Key Data Payload is converted from a MIP 
Vendor/Organization-Specific Extension to a Vendor Specific RADIUS 
Attribute (VSA). 


Upon receipt of the RADIUS Access Request, the RADIUS AAA Server 
decrypts the MIP_Key_ Data payload using the RSA private (decryption) 
key associated with the RSA public (encryption) used to encrypt the 
MIP_Key_ Data payload. The MIP_Key Data is defined as follows: 


MIP_Key_ Data = RSA_Public_Key [MN_AAAH key, MN_HA key, CHAP_key, 
MN_Authenticator, AAA Authenticator], Public_Key_ID, DMUV 


Where: 


MN_AAAH key = 128-bit random MN / RADIUS AAA Server key 
(encrypted) 


MN_HA key = 128-bit random MN / Home Agent (HA) key (encrypted) 
CHAP_key = 128-bit random Simple IP authentication key (encrypted) 
Note: the Simple IP CHAP key is not the same as the AT-CHAP key 


used for A12 Interface authentication [11]. 


MN_Authenticator = 24-bit random number (displayed as an 8 decimal 
digit number). (To be used for 1xEV-DO networks.) (encrypted) 
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AAA Authenticator = 64-bit random number used by MN to 
authenticate the RADIUS AAA Server. (encrypted) 


DMU Version (DMUV) = 4-bit identifier of DMU version. 


Public Key Identifier (Public_Key_ID) = PKOID, PKOI, PK_Expansion, 
ATV 


Where: 


Public Key Organization Identifier (PKOID) = 8-bit serial number 
identifier of Public Key Organization (PKO) that created the 
Public Key. 


Public Key Organization Index (PKOI) = 8-bit serial number used at 
PKO discretion to distinguish different public/private key 
pairs. 


PK_Expansion = 8-bit field to enable possible expansion of PKOID 
or PKOI fields. (Note: Default value = OxFF) 


Algorithm Type and Version (ATV) = 4-bit identifier of the 
algorithm used. 


Note: If 1024-bit RSA is used, the encrypted portion of the payload 
is 1024 bits (128 bytes) long. With the 28-bit Public Key Identifier 
and 4-bit DMUV, the total MIP_Key_ Data payload is 132 bytes long. 


4.6. RSA Key Management 


The wireless service provider or carrier MUST generate the RSA 
Public/Private key pair(s). An organization within the service 
provider MUST be designated by the service provider to generate, 
manage, protect, and distribute RSA Private keys (to the RADIUS AAA 
Server) and public keys (to the MN manufacturers) in support of the 
DMU procedure. 


Each RSA public/private key pair, generated by the wireless carrier, 
MUST be assigned a unique Public Key Identifier in accordance with 
Section 9. 


RSA Private keys MUST be protected from disclosure to unauthorized 
parties. The service provider organization with the responsibility 
of generating the RSA public/private key pairs MUST establish an RSA 
key management policy to protect the RSA Private (decryption) keys. 


RSA public keys MAY be freely distributed to all MN manufacturers 
(along with the Public Key Identifier). Because one RSA public key 
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can be distributed to million of MNs, it is acceptable to distribute 
the RSA public key (and Public Key Identifier) to MN manufacturers 
via e-mail, floppy disk, or a Website. The preferred method is to 
simply publish the RSA public key and associated Public Key 
Identifier in the DMU Requirements document sent to each MN 
manufacturer/OEM. 


When public keys are distributed, the public keys MUST be protected 
against alteration. If an invalid public key is programmed into a 
terminal, the terminal may be denied service because DMU cannot be 
performed successfully. 


RSA Private keys MAY be loaded into the RADIUS AAA server manually. 
Access to the RADIUS AAA Server RSA Private keys MUST be restricted 
to authorized personnel only. 


The wireless service provider MAY accept RSA Private key(s) (and 
Public Key Identifier) from MN manufacturers that have preloaded MNs 
with manufacturer-generated RSA public keys. 


4.7. RADIUS AAA Server 


The RADIUS AAA Server used for DMU MUST support the DMU Procedure. 
The AAA Server MUST support RSA public key cryptography and maintain 
a database of RSA Private (decryption) keys indexed by the Public Key 
Identifier. 


Delivery of the RSA Private key(s) to an AAA Server from the MN 
manufacturer(s) is outside the scope of this document. However, RSA 
Private key(s) delivery via encrypted e-mail or physical (mail) 
delivery is likely acceptable. 


Access to the RADIUS AAA Server MUST be limited to authorized 
personnel only. 


The RADIUS AAA Server MUST support 1024-bit RSA decryption. 


The RADIUS AAA Server MUST maintain a database of RSA public/private 
key pair indexed by the Public Key Identifier. 


The RADIUS AAA Server MUST support the RADIUS attributes specified in 
Section 8. 


The RADIUS AAA Server MUST support a subscriber-specific MIP Update 
State Field. When the MIP Update State Field is set to UPDATE KEYS 
(1), the RADIUS AAA Server MUST initiate the DMU procedure by 

including the MIP_Key_ Request attribute in an Access Reject message 
sent to the PDSN. The MIP Update State Field MAY be set to UPDATE 
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KEYS (1) by the service provider's Billing/Provisioning system based 
on IT policy. Upon verification of MN-AAA Authentication Extension 
using the decrypted MN_AAA key, the RADIUS AAA Server MUST set the 
MIP Update State Field to KEYS UPDATED (2). Upon verification of the 
MN-Authentication Extension on a subsequent RRQ/ARQ, the RADIUS AAA 
Server MUST set the MIP Update State Field to KEYS VALID (0). 


Note that the inclusion of a vendor-specific attribute in the Access 
Reject message is not consistent with Section 5.44 of [4]. A RADIUS 
AAA server that supports DMU SHOULD NOT include a vendor-specific 
attribute if the corresponding Access Request message was not 
received from a DMU-compliant PDSN. This use of Access Reject is 
strongly discouraged for any future work based on this document. 
Future work should consider the use of Access-Challenge to carry this 
vendor-specific attribute. 


The RADIUS AAA Server MUST maintain a MIP Update State Field, for 
each subscription, in one of three states (0 = KEYS VALID, 1 = UPDATE 
KEYS, 2 = KEYS UPDATED). 


The RADIUS AAA Server MUST decrypt the encrypted portion of the 
MIP_Key_Data payload using the appropriate RSA Private (decryption) 
key. 


The RADIUS AAA Server MUST check the MN_AAA Authentication Extension 
of the DMU RRQ using the decrypted MN_AAA key. 


The RADIUS AAA Server MUST include the AAA Authenticator in the 
Access Accept as a Vendor-Specific RADIUS Attribute. 


The RADIUS AAA Server MUST support the MN_Authenticator options 
specified in Section 6.1. 


The RADIUS AAA Server MUST comply with DMU Procedure failure 
operation specified in Section 5. 


The RADIUS AAA Server MUST support manual hexadecimal entry of MN_AAA 
key, MN_HA key, and Simple IP CHAP key via the AAA GUI for each 
subscription. 


The RADIUS AAA Server MUST provide a mechanism to validate the 
MIN/International Mobile Subscriber Identity (IMSI). When the 
MIN/IMSI validation is on, the RADIUS AAA Server MUST compare the 
MIN/IMSI sent from the PDSN with the MIN/IMSI in the AAA subscription 
record/profile. If the MINs or IMSIs do not match, the RADIUS AAA 
Server MUST send an Access Reject to the PDSN/FA. The Access Reject 
MUST NOT contain a MIP Key Data request 
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When the "Ignore MN_Authenticator" bit is not set, the RADIUS AAA 
Server MUST check whether MN_AuthenticatorMN = MN_AuthenticatorAAA. 
If the MN_Authenticators do not match, the RADIUS AAA Server MUST 
send an Access Reject to the PDSN/FA. The Access Reject MUST NOT 
contain a MIP_Key_Data request. 


The RADIUS AAA Server MUST include its PKOID (or another designated 
PKOID) in the MIP_Key_Request RADIUS Attribute. 


The RADIUS AAA Server MUST compare the PKOID sent in the MIP_Key_Data 
RADIUS Attribute with a list of valid PKOIDs in the RADIUS AAA 
Server. If the PKOID is not valid, the RADIUS AAA Server MUST send 
an Access Reject to the PDSN with the "Invalid Public Key" Verizon 
Wireless RADIUS Vendor Specific Attribute (VSA). Note: the same 
RADIUS attribute may be assigned a different Vendor identifier. 


Note that the inclusion of a vendor-specific attribute in the Access 
Reject message is not consistent with section 5.44 of [4]. A RADIUS 
AAA server that supports DMU SHOULD NOT include a vendor-specific 
attribute if the corresponding Access Request message was not 
received from a DMU-compliant PDSN. This use of Access Reject is 
strongly discouraged for any future work based on this document. 
Future work should consider the use of Access-Challenge to carry this 
vendor-specific attribute. 


The RADIUS AAA Server MUST support delivery of the MN-HA key using 
3GPP2 RADIUS VSAs as specified in 3GPP2 X.S0011-005-C. The 3GPP2 
VSAs used are the MN-HA Shared Key (Vendor-Type = 58) and MN-HA 
Security Parameter Index (SPI) (Vendor-Type = 57). 


The RADIUS AAA Server SHOULD always accept an Access Request from a 
cdma2000(R) Access Node (AN) for a particular subscriber when the 
UPDATE KEYS (1) and KEYS UPDATED (2) states are set. In the KEYS 
VALID (0) state, the RADIUS AAA Server MUST check the Access Request 
normally. 


The RADIUS AAA Server MUST reject an Access Request with the 
MIP_Key_Data RADIUS Attribute while the RADIUS AAA Server is in the 
KEYS VALID state, i.e., the AAA MUST NOT allow an unsolicited key 
update to occur. 


4.8. MN (Handset or Modem) 


The MN manufacturer MUST pre-load the Wireless Carrier RSA public key 
(and Public Key Identifier). 


The MN manufacturer MUST pre-generate and pre-load the 
MN_Authenticator. 
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The MN MUST support 1024-bit RSA Encryption using the pre-loaded RSA 
public key. 


The MN MUST support MN_AAA, MN_HA, and CHAP random/pseudo-random key 
generation (in accordance with RFC 4086). 


The MN MUST support random/pseudo-random AAA Authenticator and 
MN_Authenticator generation (in accordance with RFC 4086). 


Upon power-up of an MN handset or launch of the MN client, the MN 
MUST check whether a MIP_Key_Data payload has been computed. If no 
MIP_Key_Data payload exists, the MN MUST generate and store a 
MIP_Key_Data payload. The MN MUST maintain at least one pre- 
generated MIP_Key_Data payload. 


The MN MUST construct the MIP_Key_Data payload in accordance with 
Section 4.5. 


The MN MUST initiate the DMU Procedure upon receipt of a MIP 
Registration Reply (RRP) with the MIP_Key_Request Verizon Wireless 
Vendor/Organization-Specific Extension (VSE). 


Upon receipt of an RRP including the MIP_Key_Request, the MN MUST 
check the PKOID sent in the MIP_Key_Request. If the MN has a public 
key associated with the PKOID, the MN MUST encrypt the MIP_Key_Data 
payload using that public key. 


The MN MUST have the capability to designate one public key as the 
default public key if the MN supports multiple public keys. 


The MN MUST insert the Verizon Wireless MIP_Key Data VSE (or another 
Organization-specific MIP_Key_ Data VSE) after the Mobile-Home 
Authentication Extension, but before the MN-AAA Authentication 
Extension. The MIP_Key Data Extension must also be located after the 
FA Challenge Extension, if present. 


Note: The order of the extensions is important for interoperability. 
After the FA receives the Access Accept from the RADIUS AAA server, 
the FA may strip away all MIP extensions after the Mobile-Home 
Authenticator. If this occurs, it is not necessary for the HA to 
process the DMU extensions. Other compatibility problems have also 
been identified during testing with FAs from various vendors who 
place extensions in various locations. Explicit placement of the 
extensions eliminates these issues. 


Upon initiation of the DMU Procedure, the MN MUST compute the MIP 
authentication extensions using the newly-generated temporary MN_AAA 
and MN_HA keys. Upon receipt of the AAA Authenticator MIP Extension, 
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the MN MUST compare the AAA AuthenticatorMN (sent in the encrypted 
MIP_Key_Data payload) with the AAA AuthenticatorAAA (returned by the 
RADIUS AAA Server). If both values are the same, the MN MUST 
designate the temporary MN_AAA, MN_HA key, and the Simple IP CHAP key 
as permanent. The MN MUST set its MIP Update State field to KEYS 
VALID. 


The MN MUST support reset (re-generation) of the MN_Authenticator by 
the MN user as specified in Section 6.2. 


The MN MUST enable the MN user to view the MN_Authenticator. 
MN_Authenticator (24-bit random number) MUST be displayed as an 8 
decimal digit number as specified in Section 6.2. 


The MN manufacturer MUST pre-load each MN with a unique random 24-bit 
MN_Authenticator. 


Upon reset of the MN_Authenticator, the MN MUST delete all 
MIP_Key_Data payloads based on the old MN_Authenticator and generate 
all subsequent MIP_Key_Data payloads using the new MN_Authenticator 
(until the MN_Authenticator is explicitly re-set again by the MN 
user). 


The MN MUST support manual entry of all cryptographic keys such as 
the MN_AAA, MN_HA, and Simple IP CHAP key. MN MUST support 
hexadecimal digit entry of a 128-bit key. (Note: certain Simple IP 
devices only enable ASCII entry of a password as the CHAP key. It is 
acceptable for future devices to provide both capabilities, i.e., 
ASCII for a password or hexadecimal for a key. The authors recommend 
the use of strong cryptographic keys.) 


The MN MUST support the Verizon Wireless MIP Vendor/Organization- 
Specific Extensions specified in Section 9. 


The MN MUST update the RRQ Identification field when re-transmitting 
the same MIP_Key_Data in a new RRO. 


The MN MUST comply with the DMU Procedure failure operation specified 
in Section 5. 


The RSA public key MAY be stored in the MN flash memory as a constant 
while being updatable via software patch. 
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4.9. PDSN / Foreign Agent (FA) 


The PDSN MUST support the Verizon Wireless RADIUS Vendor-Specific 
Attributes (VSA) specified in Section 8 and the Verizon Wireless MIP 
Vendor/Organization-Specific Extensions (VSEs) specified in Section 
9. 


The PDSN MAY support the RADIUS VSAs specified in Section 8 and the 
MIP VSEs specified in Section 9 using another Organization 
identifier. 


Upon receipt of an Access Reject containing the 
MIP_Key_Update_Request VSA, PDSN MUST send an RRP to the MN with the 
MIP_Key_Request VSE. The PDSN MUST use the RRP error code = 89 
(Vendor Specific) and MUST not tear down the PPP session after 
transmission. 


Upon receipt of an Access Reject containing the AAA Authenticator 
VSA, the PDSN MUST send an RRP with the AAA Authenticator MIP VSE. 
The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST 
NOT tear down the PPP session after transmission. 


Upon receipt of an Access Reject containing the Public Key Invalid 
VSA, the PDSN MUST send an RRP with the Public Key Invalid MIP VSE. 
The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST 
NOT tear down the PPP session after transmission. 


Note that the inclusion of a vendor-specific attribute in the Access 
Reject message is not consistent with section 5.44 of [4]. A PDSN 
that supports DMU MUST accept an Access Reject message containing a 
vendor-specific attribute. This use of Access Reject is strongly 
discouraged for any future work based on this document. Future work 
should consider the use of Access-Challenge to carry this vendor- 
specific attribute. 


Upon receipt of an RRQ with the MIP_Key_Data VSE, the PDSN MUST 
convert the RRQ to an ARQ with the MIP_Key_Data VSA. The PDSN MUST 
send the ARQ to the RADIUS AAA server. 


The PDSN/FA MUST comply with the DMU Procedure failure operation 
specified in Section 5. 


The PDSN/FA MUST include the PKOID from the Access Reject 


MIP_Key_Update_Request VSA in the MIP_Key_ Request MIP VSE sent to the 
MN. 
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4.10. Home Agent (HA) 


The HA MUST support the Verizon Wireless MIP Vendor/Organization- 
Specific Extensions (VSEs) specified in Section 9. (Note: the HA may 
not encounter a DMU MIP extension if the FA strips away all 
extensions after the Mobile-Home authentication extension.) 


The HA MAY support the MIP VSEs specified in Section 9 using another 
Organization identifier. (Note: the HA may not encounter a DMU MIP 
extension if the FA strips away all extensions after the Mobile-Home 
authentication extension.) 


The HA MUST support delivery of the MN-HA key from the Home RADIUS 
AAA server using 3GPP2 RADIUS Vendor-Specific Attributes (VSA) as 
specified in 3GPP2 X.S0011-005-C. The 3GPP2 VSAs used are the MN-HA 
Shared Key (Vendor-Type = 58) and the MN-HA SPI (Vendor-Type = 57). 


4.11. DMU Procedure Network Flow 


This section provides a flow diagram and detailed description of the 
process flow involving the Dynamic Mobile IP Update procedure process 
within the IS-2000 network. 
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MN PDSN/FA AAAH 


| 1: RSA Public Key | | RSA Private Key | 

| Pre-loaded by | | Pre-loaded by 

| Manufacturer | | | Service Provider | 
| 


2: MS/BS: IS-2000 Call Origination and Authentication 
3: MN/PDSN/FA: PPP Session Establishment 


| 4: Registration Request (RRQ) | 


6: MIP Update State | 
is UPDATE KEYS | 


| 

| 

| 7: Access Reject with 
| MIP_Key_Update_Request 
| RADIUS Attribute 

| 

| 

| 

| 


8: Registration Reply (RRP) 
with MIP_Key_ Request MIP | 
Vendor/organization-specific | 
extension | 
<--------------------------------- | 
| 9: MN generates | | 
| MIP_Key_Data | | 
| using temporary | | 
| MIP keys | | 
10: RRQ with MIP_Key_Data | 
Vendor/organization-specific extension 
O A SS > | 11: Access Request 
| w/MSID 
and MIP_Key_Data 
| RADIUS attribute 


Figure 4. DMU Procedure Flow (part 1) 
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MN PDSN/FA AAAH 


| 12: decrypt 

| MIP_Key_Data, 

| verify MN-AAA 
authentication 
| 


extension, set 
MIP Update State 
= KEYS UPDATED | 


13: Access Reject with 
AAA Authenticator 
RADIUS Attribute 


| 
| 
| 
<---—-—------ - 
14: Registration Reply (RRP) 
with AAA Authenticator MIP | 
Vendor/organization-specific | | 
extension | | 
a | | 
| 15: verify | | | 
| AAA Authenticator, | | | 
| store temporary | | | 
| MIP keys as | | | 
| permanent keys | | 
| 16: RRQ | 
| ia iii ad R a > | Access Request 
| | w/MSID 
| |------------ >| 
| ae 
17: verify MN-AAA 
| | | authentication 
| | | extension, set | 
| | | MIP Update State | 
| | | = KEYS VALID | 
| QQ 
| A 
| 


Figure 4. DMU Procedure Flow (part 2) 
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MN PDSN/FA AAAH HA 


| 18. Registration Request (RRO) | 
| --=---~-=------------=--=------- >| 
19: Access Request | 
[<----------------- | 
| Access Accept | 

with MN-HA key 


| verify 

| mobile-home 

| authentication 
| extension 


20. Registration Reply (RRP) | 


Figure 4. DMU Procedure Flow (part 3) 
Each step in the Figure 4 DMU Process is described as follows: 


1. Each RSA public/private key pair MUST be generated in 
accordance with RFC 3447. Each public/private key pair MUST 
be assigned a unique Public Key Identifier (PKOID) by its 
creator. 


If the service provider does not generate the public/private 
key pair and deliver the RSA public key to the MN manufacturer 
for pre-installation in the MN, the MN manufacturer MUST 
generate the RSA public/private key pair (using a 1024-bit 
modulus) and pre-load all MNs with the RSA public (encryption) 
key. The MN manufacturer MUST distribute the RSA Private 
(decryption) key, in a secure manner, to the appropriate 
service provider. 


2. Assuming that the cdma2000(R) 1X MN has been provisioned with 
an A-key and SSD, the cdma2000(R) 1X MS initiates a call 
origination and authenticates itself to the IS-2000 network. 
Upon IS-2000 authentication success, the BS sends the 
"authenticated" MSID (e.g., MIN) to the PDSN. 

3. The MN and PDSN establish a PPP session. 


4. The MN sends a MIP Registration Request (RRQ) to the PDSN. 
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The PDSN converts the MIP RRQ into a RADIUS Access Request 
(ARQ) message, includes the MSID in the ARQ, and forwards the 
ARQ to the Home RADIUS AAA server. 


The RADIUS AAA Server compares the authenticated MSID (sent 
from the PDSN) with the MSID in its subscriber database 
(associated with the NAI). If the AAA MIP Update State Field 
is set to UPDATE KEYS (1), the RADIUS AAA Server rejects 
Packet Data access and orders a MIP key update. 


The RADIUS AAA Server sends an Access Reject (code = 3) 
message to the PDSN with the MIP_Key_Update_Request RADIUS 
VSA. 


The PDSN converts the Access Reject to a MIP Registration 
Reply (RRP) with a MIP_Key_Request MIP VSE and sends the RRP 
to the MN. RRP Code = 89 (Vendor Specific). 


The MN sets the MN MIP Update State = UPDATE KEYS. If the MN 
has no pre-generated and pre-encrypted MIP_Key_Data payload, 
the MN MUST generate the MN_AAA key, MN_HA key, Chap key, 
MN_Authenticator, and AAA Authenticator in accordance with RFC 
4086. Except for the Public Key Identifier, all generated 
values MUST be encrypted using the pre-loaded RSA public 
(encryption) key. The newly generated MN_AAATEMP Key and 
MN_HATEMP MUST be used to calculate the MN-AAA and Mobile-Home 
Authentication Extensions for the current RRQ. Note: the MN 
MAY pre-compute the MIP_Key Data payload by checking whether a 
payload exists during each MN power-up or application 
initiation. 


The MN sends the RRQ with MIP_Key Data MIP VSE to the PDSN. 


The PDSN converts the RRQ to a RADIUS ARQ with MIP_Key Data 
RADIUS VSA and forwards the ARQ to the home RADIUS AAA Server. 
The MSID is included in the ARQ. 


The RADIUS AAA Server compares the authenticated MSID (sent 
from the PDSN) with the MSID in its subscriber database 
(associated with the NAI). If MSIDPDSN = MSIDAAA, the RADIUS 
AAA server, using the Public Key Identifier, determines the 
appropriate RSA Private key and decrypts the encrypted portion 
of the MIP_Key Data payload. The RADIUS AAA Server verifies 
the MN-AAA Authentication Extension Authenticator using the 
decrypted MN_AAA key. If successful, the RADIUS AAA Server 
updates the subscriber profile with the decrypted MN_AAA key, 
MN_HA key, and CHAP key. The RADIUS AAA Server sets the AAA 
MIP Update State Field to KEYS UPDATED (2). 
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The RADIUS AAA Server sends an Access Reject with 
AAA Authenticator RADIUS VSA to the PDSN. 


The PDSN converts the Access Reject to a MIP RRP with 
AAA Authenticator MIP VSE. RRP Code = 89 (Vendor Specific). 


If AAA AuthenticatorMN = AAA AuthenticatorAAA, the MN assigns 
MN_AAATEMP to MN_AAA key and MN_HATEMP to MN_HA key (MN MIP 
Update State = KEYS VALID). Otherwise, the MN discards the 
temporary keys. 


The MN initiates a new RRQ that is converted to an ARO by the 
PDSN and forwarded to the RADIUS AAA Server. 


The RADIUS AAA Server verifies the MN-AAA Authentication 
Extension and sets the AAA MIP Update State Field to KEYS 
VALID (0). The RADIUS AAA Server sends an Access Accept to 
the PDSN/FA. 


The PDSN/FA sends the RRQ to the Home Agent (HA). 


The HA sends an Access Request to the RADIUS AAA Server. The 
RADIUS AAA Server sends an Access Accept to the HA with the 
MN_HA key. The HA verifies the Mobile-Home Authentication 
Extension using the MN_HA key. 


The HA sends an RRP to the PDSN/FA, which forwards the RRP to 
the MN. RRP Code = 0 (Success). 


5. DMU Procedure Failure Operation 


To improve the robustness of the DMU Procedure to account for 
interruptions due to UDP message loss, RRQ retransmission, or MN 
failure, the RADIUS AAA Server MUST maintain a MIP Update State 


Field, 


for each subscription, in one of three states (0 = KEYS VALID, 


1 = UPDATE KEYS, 2 = KEYS UPDATED). 
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MN PDSN/FA AAAH HA 
| MN state = | | AAAH state = | 
| KEYS VALID | | | UPDATE KEYS | 
A MN a | AAA E 

| (A) RRO | | 

|-------------- >| ARQ | 
| ------------- > 
AR (Key_Update) 
(B) RRP (Key_Update) |<------------- | 

| > | 
| MN state = | | | 
| UPDATE KEYS | | 

(C) RRQ (MIP_Key_Data) | 
ooo >| ARQ (MIP_Key_ Data) 
e > | 


| MN state = | 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| | AAAH state = | | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 
KEYS VALID 
---------------- | | 
| RRO | | 
[SA >| ARQ | 
| |------------- >| 
| | AAAH state = | 
| | KEYS VALID | 
| Noss cannes 
| aa | 
<------------- | RRQ 
A AA PP A Oe EAER E > 
| ARQ 
| | | > | 
| | | AA | 
| | |---------------- >| 
| | | RRP | 
| RRP. |<---------------- 
< a A O oi Fi A o e e a a a id 
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Each step in Figure 5 is described as follows: 


1. If (A) is lost, the MN retransmits (A). The RADIUS AAA server 
expects (A). If the AAA server is in the UPDATE KEYS state, 
the RADIUS AAA Server sends AR with MIP_Key_Update_Request VSA, 
and the PDSN/FA sends (B). 


2. If (B) is lost, the MN retransmits (A). The RADIUS AAA server 
expects (C). If it receives (A), the RADIUS AAA Server sends 
AR with MIP_Key_Update_Request VSA, and the PDSN/FA retransmits 
(B). 

3. If (C) is lost, the mobile retransmits (C). The RADIUS AAA 


server expects (C) and updates the MIP keys appropriately. The 
RADIUS AAA server transitions to KEYS UPDATED and commits the 
MIP_Key Data. The RADIUS AAA Server sends the AR with 

AAA Authenticator VSA, and the PDSN/FA replies to the MN with 
(D). 


4. If (D) is lost, the mobile retransmits (C) using the same key 
data sent previously. The RADIUS AAA server expects (A) using 
the same keys. 


a. If the RADIUS AAA server receives (C) with the same keys it 
received previously, it retransmits the AR with 
AAA Authenticator VSA and the PDSN replies with (D), 
containing the AAA Authenticator. 


b. If the RADIUS AAA server receives (C) with different keys 
than it received previously, the RADIUS AAA Server sends AR 
with MIP_Key Update_Request VSA, the PDSN/FA retransmits 
(B), and the RADIUS AAA server transitions to UPDATE KEYS. 


c. If the RADIUS AAA server receives (A), which fails 
authentication using the keys sent in (C), the RADIUS AAA 
Server sends AR with MIP_Key_Update_Request, the PDSN/FA 
retransmits (B), and the RADIUS AAA server transitions to 
UPDATE KEYS. 


5. Once the PDSN/FA receives (A), forwards the ARQ to the RADIUS 
AAA server, and the MN-AAA Authenticator is verified using the 
MN_AAA key, the RADIUS AAA Server transitions to the KEYS VALID 
state and the DMU process is complete. 
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The AAA DMU state machine is described in Figure 6. 


Auth success using  -------------- Need Key 
MIP_Key_Data Update 


| | 
| | 
| | 
| Auth failed (invalid keys) | 
| or RRQ with different MIP_Key_Data | 
| | 
| v 


| | 
| v 
| KEYS UPDATED | | UPDATE KEYS | 
Ooi | 
RRQ with same Got MIP_Key_Data 


MIP_Key_Data 
Figure 6. RADIUS AAA Server DMU State Machine 
6. cdma2000(R) HRPD/1xEV-DO Support 


Because the DMU Procedure occurs at the IP Layer, the DMU Procedure 
supports MIP key distribution in either the cdma2000 (R) 1X or 
HRPD/1xEV-DO network. Because the cdma2000 (R) HRPD/1xEV-DO network 
does not provide Radio Access Network (RAN) authentication, the DMU 
Procedure is more susceptible to a false MN attack (than in an 
cdma2000 (R) 1X network with Cellular Authentication and Voice 
Encryption (CAVE) RAN authentication). For this reason, the DMU 
Procedure has the capability to optionally support device-to-network 
authentication using the MN_Authenticator. 


The method of MN_Authenticator delivery to the RADIUS AAA server is 
outside the scope of this document, allowing service providers the 
flexibility to determine the most efficient/least intrusive procedure 
to support MN authentication during the DMU Procedure. 

6.1. RADIUS AAA Support 
The RADIUS AAA server MUST support three MN_Authenticator options: 


1. Ignore MN_Authenticator 


Depending on other potential authentication/fraud prevention 
options (outside the scope of the DMU Procedure), the RADIUS AAA 
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Server MUST have the capability to ignore the MN_Authenticator. 
For example, when the RADIUS AAA Server decrypts the MIP_Key_Data 
payload, the AAA Server silently discards the MN_Authenticator. 


2. Pre-Update Validation 


Prior to updating a subscription profile with the delivered MIP 
keys, the RADIUS AAA Server MUST compare the MN_AuthenticatorMN 
(delivered via the encrypted MIP_Key_Data payload) with the 
MN_AuthenticatorAAA (possibly delivered via the service provider 
customer care or billing/provisioning system). 


3. Post-Update Validation 


After the DMU Procedure is complete, the RADIUS AAA Server stores 
the delivered MN_AuthenticatorMN and waits for delivery of the 
MN_AuthenticatorAAA (via Customer Care, interactive voice response 
(IVR), or some other unspecified process). Once the 
MN_Authenticator is delivered to the RADIUS AAA Server, the AAA 
MUST compare the MN_AuthenticatorMN (delivered via the encrypted 
MIP_Key_Data payload) with the MN_AuthenticatorAAA. If the 
Authenticators match, the RADIUS AAA Server authorizes access and 
final update of the MIP keys. 


6.2. MN Support 
The Mobile Node (MN) MUST store the 24-bit MN_Authenticator. 


The MN MUST display the MN_Authenticator as an 8 decimal digit number 
(via LCD display on a handset or via a GUI for a modem). If the MN 
resides within a handset, the user MAY display the MN_Authenticator 
using the following keypad sequence: "FCN + * + * +M+I+P+ 
RCL". Otherwise, the MN MUST display the MN_Authenticator via the 
device’s GUI. 


The MN MUST have the capability to reset the MN_Authenticator. In 
other words, the MN MUST have the capability to randomly/pseudo- 
randomly generate a new 24-bit MN_Authenticator upon user command, in 
accordance with RFC 4086. The reset feature mitigates possible 
compromise of the MN_Authenticator during shipment/storage. If the 
MN resides within a handset, the user MAY reset the MN_Authenticator 
using the following keypad sequence: "FCN + * + * +M+HI1I+P+CH# 
C + RCL". Otherwise, the MN MUST reset the MN_Authenticator via the 
device’s GUI. 


The MN manufacturer MAY pre-load the MN with the MN_Authenticator. 


For example, by pre-loading the MN_Authenticator and affixing a 
sticker with the MN_Authenticator (8 decimal digit representation) to 
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the MN (e.g., modem), the point-of-sale representative does not have 
to retrieve the MN_Authenticator from the MN interface. 


[Optional] The MN MAY maintain a separate primary and secondary queue 
of MN_Authenticator/MIP_Key_Data Payload pairs. When the MN user 
resets the primary MN_Authenticator, the MN discards the primary 
MN_Authenticator (and any associated MIP_Key_Data Payload) and 
assigns the MN_Authenticator in the secondary queue as the primary 
MN_Authenticator (and assigns any associated MIP_Key_Data Payloads to 
the primary queue). This feature enables the user/provisioner to 
reset the MN_Authenticator and immediately initiate the DMU procedure 
without losing the MIP_Key_Data Payload pre-encryption advantage. 
Upon MN_Authenticator transfer from the secondary to primary queue, 
the MN MUST generate a new MN_Authenticator and associated 
MIP_Key_Data Payload for the secondary queue. The MN MUST check both 
the primary and secondary MN_Authenticator/MIP_Key_Data Payload 
queues upon power-up or application initiation. The MN MUST maintain 
at least one MN_Authenticator/MIP_Key_Data Payload pair in each 
queue. 


6.3. Informative: MN_Authenticator Support 


MN authentication using the MN_Authenticator gives the service 
provider the maximum flexibility in determining how to deliver the 
MN_Authenticator to the RADIUS AAA Server. The method of 
MN_Authenticator delivery is outside the scope of this document. 


However, to provide some context as to how the MN_Authenticator may 
support MN authentication/fraud prevention in the HRPD/1xEV-DO 
environment, we describe the following possible provisioning 
scenario. 


When a subscriber initially acquires their HRPD/1xEV-DO device and 
service, the point-of-sale representative records the subscription 
information into the billing/provision system via a computer terminal 
at the point-of-sale. The billing/provisioning system delivers 
certain information to the RADIUS AAA Server (e.g., NAI, MSID, 
Electronic Serial Number (ESN)) including the MN_Authenticator, which 
the point-of-sale representative retrieves via the MN device’s 
display. In the case of a modem, the manufacturer may have pre- 
loaded the MN_Authenticator and placed a copy of the MN_Authenticator 
on a sticker attached to the modem. The point-of-sale representative 
simply copies the 8 decimal digit value of the MN_Authenticator into 
the customer profile. Once the MN is loaded with the proper NAI and 
powered-up, the MN initiates the DMU Procedure with the RADIUS AAA 
Server. The RADIUS AAA Server compares the MN-delivered 
MN_Authenticator with the billing-system-delivered MN_Authenticator. 
If the authenticators match, the RADIUS AAA Server updates the 
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subscriber profile with the delivered MIP keys and authorizes 
service. If the Post-Update option is enabled within the RADIUS AAA 
Server, the RADIUS AAA Server tentatively updates the subscription 
profile until it receives the MN_Authenticator via the 
billing/provision system. 


As another option, the service provider MAY use an IVR system in 
which the HRPD/1xEV-DO subscriber calls a provisioning number and 
inputs the MN_Authenticator. The IVR system then delivers the 
MN_Authenticator to the RADIUS AAA Server for final validation and 
Packet Data Access. 


7. Security Considerations 


The DMU Procedure is designed to maximize the efficiency of MIP key 
distribution while providing adequate key distribution security. The 
following provides a description of potential security 
vulnerabilities and their relative risk to the DMU Procedure: 


7.1. Cryptographic Key Generation by the MN 


Because the MN is required to properly generate the MN_AAA, MN_HA, 
and CHAP key, the MN must perform cryptographic key generation in 
accordance with accepted random/pseudo-random number generation 
procedures. MN manufacturers MUST comply with RFC 4086 [12] 
guidelines, and service providers SHOULD ensure that manufacturers 
implement acceptable key generation procedures. The use of 
predictable cryptographic keys could be devastating to MIP security. 
However, the risk of not using acceptable random/pseudo-random key 
generation is minimal as long as MN manufacturers adhere to RFC 4086 


guidelines. Furthermore, if a key generation flaw is identified, the 
flaw appears readily correctable via a software patch, minimizing the 
impact. 


7.2. Man-in-the-Middle Attack 


The DMU procedure is susceptible to a Man-in-the-Middle (MITM) 
attack; however, such an attack appears relatively complex and 
expensive. When Authentication and Key Agreement (AKA) is deployed 
within cdma2000(R) 1X, the MITM Attack will be eliminated. The risk 
of an MITM Attack is minimal due to required expertise, attack 
expense, and impending cdma2000(R) 1X mutual authentication 
protection. If a particular cdma2000(R) 1X network does not support 
A-key authentication, the MN_Authenticator MAY optionally be used. 
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7.3. RSA Private Key Compromise 


Because one RSA Private key may be associated with millions of MNs 
(RSA public key), it is important to protect the RSA Private key from 
disclosure to unauthorized parties. If a MN manufacturer is 
generating the RSA public/private key pair, the MN manufacturer MUST 
establish adequate security procedures/policies regarding the 
dissemination of the RSA Private key to the appropriate service 
provider. An RSA Private key SHOULD be distributed to a legitimate 
cdma2000(R) service provider only. If a service provider is 
generating their own RSA public/private key pair, the service 
provider MUST protect the RSA Private key from disclosure to 
unauthorized parties. 


7.4. RSA Encryption 
Several vulnerabilities have been identified in certain 


implementations of RSA; however, they do not appear applicable to the 
DMU Procedure. 


7.5. False Base Station/PDSN 


The MN appears to be protected against a false BS denial-of-service 
(DOS) attack, since only the proper RADIUS AAA server can recover the 
AAA Authenticator. This method of preventing a false base station 
attack assumes security of the network messaging between the AAA and 
the serving system, as discussed in Section 7.9. 


7.6. cdma2000(R) 1X False MN 
The cdma2000(R) 1X network appears adequately protected against a 
false MN by IS-2000 challenge-response authentication. If DMU is 
used outside the cellular domain, equivalent authentication 
procedures are required for the same level of security. 


7.7.  HRPD/1xEV-DO False MN 


The 1xEV-DO RADIUS AAA Server MAY optionally authenticate the MN 
using the MN_Authenticator to prevent a fraudulent MN activation. 


7.8. Key Lifetimes 
There is no explicit lifetime for the keys distributed by DMU. 
The lifetime of the keys distributed by DMU is determined by the 


system operator through the RADIUS AAA server. The MN_AAA and MN_HA 
key lifetimes can be controlled by initiating an update as needed. 
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Furthermore, the DMU process is protected against false initiation 
because the MN cannot initiate DMU. This makes it unworkable to 
provide an explicit lifetime to the MN, since the MN cannot take any 
action to renew the keys after expiration. 


7.9. Network Message Security 


The security of the MN-HA keys delivered from the RADIUS AAA server 
to the MIP home agent requires confidentiality for network messages 
containing such keys. The specification of security requirements for 
network messages is the responsibility of the operator, and is 
outside the scope of this document. (Note that similar considerations 
apply to the distribution of Shared Secret Data, which is already 
transmitted between nodes in the ANSI-41 network.) 


If DMU is used outside the domain of a cellular operator, RADIUS 
security features MAY be used, including the Request-Authenticator 
and Response-Authenticator fields defined in [4] and the Message- 
Authenticator attribute defined in [13]. 


8. Verizon Wireless RADIUS Attributes 


Three new RADIUS Attributes are required to support the DMU Procedure 
and are specified as follows: 


Type: 26 
Length: >9 
Verizon Wireless Enterprise/Vendor ID: 12951 


MIP_Key_Update_Request: 


The Home RADIUS AAA Server includes this attribute to indicate that 
MIP key update is required. 


Vendor-Type = 1 
Vendor-Length = 3 bytes 
Vendor-Value = PKOID of the RADIUS AAA Server 


MIP_Key_Data: 


Key data payload containing the encrypted MN_AAA key, MN_HA key, CHAP 
key, MN_Authenticator, and AAA Authenticator. This payload also 
contains the Public Key Identifier. 


Vendor-Type = 2 


Vendor-Length 134 bytes 
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NOTE: Vendor-Length depends on the size of the RSA modulus. For 
example, when RSA-512 is used, Vendor-Length = 70 bytes. 

Vendor-Value = 128 byte RSA encryption payload (when 1024-bit RSA 
used), which contains encrypted MN_AAA key, MN_HA key, CHAP 
key, MN_Authenticator, and AAA Authenticator. 

The four (4) byte Public Key Identifier is concatenated to the 
encrypted payload. 


AAA Authenticator: 


The 64-bit AAA Authenticator value decrypted by the Home RADIUS AAA 
Server. 


Vendor-Type = 3 

Vendor-Length = 10 bytes 

Vendor-Value = decrypted AAA Authenticator from Home RADIUS AAA 
Server. 


Public Key Invalid: 


The home RADIUS AAA Server includes this attribute to indicate that 
the public key used by the MN is not valid. 


Vendor-Type = 4 
Vendor-Length = 2 bytes 


Vendor-Value = none. 


Note: An Organization may define RADIUS VSAs using its own 
Organization identifier. 


9. Verizon Wireless Mobile IP Extensions 
Three Verizon Wireless Mobile IP Vendor/Organization-Specific 
Extensions (VSEs) (RFC 3115), required to support the DMU Procedure, 
are specified as follows: 
Type: 38 (CVSE-TYPE-NUMBER) 
Verizon Wireless Vendor ID: 12951 (high-order octet is 0 and low 


order octets are the SMI Network Management Private Enterprise Code 
of the Vendor in the network byte order, as defined by IANA). 
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Figure 7. Critical Vendor/Organization-Specific Extension 


MIP_Key_Request: 


The Home RADIUS AAA Server includes this extension to indicate that 
MIP key update is required. 


Length = 7 


NOTE: The RFC 3115 Editor has stated that the Reserved field is 
not included in the length determination. 

Vendor-CVSE-Type = 1 

Vendor-CVSE-Value = PKOID sent in the RADIUS 
MIP_Key_Update_Request attribute. 


MIP_Key_Data: 


Key data payload containing encrypted MN_AAA key, MN_HA key, CHAP 
key, MN_Authenticator, and AAA Authenticator. This payload also 
contains the Public Key Identifier. 


Length = 138 

NOTE: Length depends on the size of the RSA modulus. For example, 
when RSA-512 is used, Length = 74 bytes. 

Vendor-CVSE-Type = 2 

Vendor-CVSE-Value = 128 byte RSA encryption payload (when 1024-bit 
RSA used) which contains encrypted MN_AAA key, MN_HA key, CHAP 
key, MN_Authenticator, and AAA Authenticator. 

The four (4) byte Public Key Identifier and DMUV is concatenated 
to the encrypted payload. 


AAA Authenticator: 


The 64-bit AAA Authenticator value decrypted by the Home RADIUS AAA 
Server. 
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10. 


Length = 14 bytes 

Vendor-CVSE-Type = 3 

Vendor-CVSE-Value = decrypted AAA Authenticator from the Home 
RADIUS AAA Server. 


Public Key Invalid: 


The Home RADIUS AAA Server includes this extension to indicate that 
the public key used by the MN is not valid. 


Length = 6 bytes 
Vendor-CVSE-Type = 4 
Vendor-CVSE-Value = none. 


Note: An Organization may define VSEs using their own Organization 
identifier. 


Public Key Identifier and DMU Version 


The Public Key Identifier (Pub_Key_ID) is used during the Dynamic 
Mobile IP Update (DMU) procedure to allow the RADIUS AAA Server to 
distinguish between different public keys (which may be assigned by 
different manufacturers, service providers, or other organizations). 
The Public Key Identifier consists of the PKOID, PKOI, PK_Identifier, 
and ATV fields. The DMU Version field enables subsequent revisions 
of the DMU procedure. 


0 7 8 15 16 23 24 27 28 31 
Figure 8. Public Key Identifier and DMUV 


Each Public Key Organization (PKO) MUST be assigned a Public Key 
Organization Identifier (PKOID) to enable the RADIUS AAA Server to 
distinguish between different public keys created by different PKOs 
(see Table 1). 


If a service provider does not provide the MN manufacturer with a 
(RSA) public key, the manufacturer MUST generate a unique RSA 
Public/Private key pair and pre-load each MN with the RSA public key 
(1024-bit modulus by default). The manufacturer MAY share the same 
RSA Private key with multiple service providers as long as reasonable 
security procedures are established and maintained (by the 
manufacturer) to prevent disclosure of the RSA Private (decryption) 
key to an unauthorized party. 
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The Public Key Organization Index (PKOI) is an 8-bit field whose 
value is defined at the discretion of the PKO. For example, a device 
manufacturer MAY incrementally assign a new PKOI for each 
Public/Private key pair when the pair is created. 


The PK_Expansion field enables support for additional PKOs or 
expansion of the PKOLI. 


The DMU Version field allows for DMU Procedure version identification 
(see Table 2). 


The Algorithm Type and Version (ATV) field allows for identification 
of the public key algorithm and version used (see Table 3). 
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Table 1. 
Public Key PKOID 
Organization (PKO) (HEX) 
RESERVED 40 
RESERVED 41 
RESERVED 42 
RESERVED 43 
RESERVED 44 
RESERVED 45 
RESERVED 46 
RESERVED 47 
RESERVED 48 
RESERVED 49 
Verizon Wireless 4A 
AAPT Ltd. 4B 
ALLTEL Communications 4C 
Angola Telecom 4D 
Bell Mobility 4E 
BellSouth International 4F 
China Unicom 50 
KDDI Corporation 51 
Himachal Futuristic 52 
Communications Ltd. 
Hutchison Telecom (HK), 53 
Ltd. 
IUSACELL 54 
Komunikasi Selular 55 
Indonesia (Komselindo) 
Korea Telecom Freetel, 56 
Inc. 
Leap 57 
LG Telecom, Ltd. 58 
Mahanagar Telephone Nigam 59 
Limited (MTNL) 
Nextel Communications, 5A 
Inc. 
Operadora UNEFON SA de CV 5B 
Pacific Bangladesh 5C 
Telecom Limited 
Pegaso PCS, S.A. DE C.V. 5D 
Informational 


June 2007 


Public Key Organization Identification Table 


Public Key 
Organization (PKO) 
Sanyo Fisher Company 
Sharp Laboratories of 
America 

Sierra Wireless, Inc. 
Sony Electronics 
Synertek, Inc. 

Tantivy Communications, 
Inc. 

Tellus Technology, Inc. 
Wherify Wireless, Inc. 
Airbiquity 

ArrayComm 

Celletra Ltd. 

CIBERNET Corporation 
CommWorks Corporation, 
a 3Com Company 

Compag Computer 
Corporation 

ETRI 

Glenayre Electronics 
Inc. 

GTRAN, Inc. 

Logica 

LSI Logic 


Metapath Software 
International, Inc. 
Metawave Communications 
Openwave Systems Inc. 


ParkerVision, Inc. 


QUALCOMM, Inc. 
QuickSilver Technologies 
Research Institute of 
Telecommunication 
Transmission, MII (RITT) 
Schema, Ltd. 


SchlumbergerSema 
ScoreBoard, Inc. 


SignalSoft Corp. 
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Public Key PKOID 
Organization (PKO) (HEX) 
Pele-Phone 5E 
Communications Ltd. 
Qwest 5F 
Reliance Infocom Limited 60 
Shinsegi Telecomm, Inc. 61 
Shyam Telelink Limited 62 
SK Telecom 63 
Sprint PCS 64 
Tata Teleservices Ltd. 65 
Telecom Mobile Limited 66 
Telstra Corporation 67 
Limited 
Telus Mobility Cellular, 68 
Inc. 
US Cellular 69 
3G Cellular 6A 
Acer Communication & 6B 
Multimedia Inc. 
AirPrime, Inc. 6C 
Alpine Electronics, Inc. 6D 
Audiovox Communications 6E 
Corporation 
DENSO Wireless 6F 
Ditrans Corporation 70 
Fujitsu Network 71 
Communication, Inc. 
Gemplus Corporation 72 
Giga Telecom Inc. 73 
Hyundai CURITEL, Inc. 74 
InnovICs Corp 75 
Kyocera Corporation 76 
LG Electronics, Inc. 77 
LinkAir Communications, 78 
Inc. 
Motorola, Inc. 79 
Nokia Corporation 7A 
Novatel Wireless, Inc. 7B 
OKI Network Technologies 7C 
Informational 


June 2007 


Public Key 
Organization (PKO) 
SmartServ Online, 

Ine: 

TDK Corporation 

Texas Instruments 
Wherify Wireless, Inc. 
Acterna 

Anritsu Company 
Ericsson 

Grayson Wireless 
LinkAir Communications, 
Inc. 

Racal Instruments 


Rohde & Schwarz 


Spirent Communications 
Willtech, Inc. 
Wireless Test Systems 


Airvana, Inc. 
COM DEV Wireless 
Conductus, Inc. 


Glenayre Electronics 
Inc. 

Hitachi Telecom (USA), 
InG: 

Hyundai Syscomm Inc. 


ISCO 

LG Electronics, Inc. 
LinkAir Communications, 
Inc. 

Lucent Technologies, 
Inc. 

Motorola CIG 

Nortel Networks 
Repeater Technologies 


Samsung Electronics Co., 
Ltd. 

Starent Networks 

Tahoe Networks, Inc. 
Tantivy Communications, 
Inc. 
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PKOID Public Key PKOID Public Key 
(HEX) Organization (PKO) (HEX) Organization (PKO) 
3D Pixo 7D WaterCove Networks 
3E Research In Motion TE Winphoria Networks, Inc. 
3F Samsung Electronics TE ZTE Corporation 
ECO, BEA: 


Note: 80 through FF will be assigned by the PKOID administrator 
(Verizion Wireless). 


Table 2. DMU Version 


DMU Version DMU Version 
Value 

00 RFC 4784 

01 Reserved 

02 Reserved 

03 Reserved 

04 Reserved 

05 Reserved 

06 Reserved 

07 Cleartext Mode 


Table 3. Algorithm Type and Version 


ATV Public Key Algorithm 
Value Type and Version 

00 Reserved 

01 RSA - 1024 

02 RSA - 768 

03 RSA - 2048 

04 Reserved 

05 Reserved 

06 Reserved 

07 Reserved 


11. Conclusion 


The Dynamic Mobile IP Key Update (DMU) Procedure enables the 
efficient, yet secure, delivery of critical Mobile IP cryptographic 
keys. The use of cryptographic keys (and hence, the bootstrapping of 
such MIP keys using the DMU Procedure) is essential to commercial 
delivery of Mobile IP service in cdma2000 1xRTT and HRPD/1xEV-DO 
networks or other networks that utilize Mobile IP. 
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Appendix A: Cleartext-Mode Operation 


DMU supports a cleartext mode for development testing where DMUV = 7. 
The MIP_Key_Data payload will assume the same size as if RSA 1024-bit 
encryption were applied to the payload. In this mode, the 
MIP_Key_Data RADIUS Attribute and MIP Vendor Specific Extension will 
be 134 bytes and 138 bytes in length, respectively. Thus, in 
cleartext mode, the payload MUST consist of 48 bytes of keys (MN_AAA, 
MN_HA, and CHAP key), 8-byte AAA Authenticator, 3-byte 
MN_Authenticator. The next 69 bytes will be padded with "0" bits. 


MIP_Key_Data = MN_AAAH key, MN_HA key, CHAP_key, MN_Authenticator, 
AAA Authenticator, Padding (69 bytes), Public_Key_IDi, DMUV 


Where: 
MN_AAA key = 128-bit random MN / RADIUS AAA Server key. 
MN_HA key = 128-bit random MN / Home Agent (HA) key. 
CHAP_key = 128-bit random Simple IP authentication key. 
MN_Authenticator = 24-bit random number. 


AAA Authenticator = 64-bit random number used by MN to 
authenticate the RADIUS AAA Server. 


Padding = 69 bytes of 0's. 


DMU Version (DMUV) = 4-bit identifier of DMU version. 
Public Key Identifier (Pub _Key_ID) = PKOID, PKOI, PK_Expansion, ATV 
Where: 

Public Key Organization Identifier (PKOID) = 8-bit serial number 


identifier of the Public Key Organization (PKO) that created 
the Public Key. 


Public Key Organization Index (PKOI) = 8-bit serial number used at 
PKO discretion to distinguish different Public/Private key 
pairs. 


PK_Expansion = 8-bit field to enable possible expansion of PKOID 
or PKOI fields. (Note: Default value = OxFF) 


Algorithm Type and Version (ATV) = 4-bit identifier of the 
algorithm used. 
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